\documentclass{article}%

\usepackage[left=1in,right=1in,top=1.2in,bottom=1.5in]{geometry}
\usepackage[T1]{fontenc}
\usepackage{kpfonts}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{enumerate}
\usepackage{graphicx}
\usepackage[bookmarks]{hyperref}

\pdfpagewidth 8.5in
\pdfpageheight 11.0in
\setlength{\parindent}{0pt}

\title{COMP 303 - Software Development}
\author{Gary Roumanis, Andrew Sutcliffe, Shen Chen Xu}

\begin{document}

\maketitle

\begin{description}
  \item[Board generation]\hfill\\
    At first, one might be tempted to build a solvable board by starting with
    an empty one, and then successively adding pairs of matching tiles according
    to the layout. This proves to be rather complicated because we need to make
    sure that we can solve the resulting board by reversing this process.
    However, we already have the game logic working from the first milestone
    and it is much easier to generate a solution to a random board than
    generating the board itself. 

    To randomly generate a solution, we start with a complete board, then
    repeatedly remove random pairs of tiles (pretending that they match) as if
    we are playing the game, until we have removed all the tiles. Next, we
    assign patterns (the drawing on the tiles) to each tile so that the
    solution we generated does consist of matching pairs, but we do so randomly
    so all possible boards can be generated. Once we have a solution, it is
    straightforward to generate the corresponding board.

    We note that for any solvable board, there exists a solution consisting of
    a sequence of matching pairs of tiles. This solution clearly has a positive
    probability of being generated during the first step of our algorithm. The
    particular tile patterns of this board has also a positive probability of
    being generated since the second part of our algorithm assigns tile
    patterns uniformly at random.

    We do need to mention that the first step have a small probability of
    failing, since we may have less than two exposed tiles at some point. This
    follows a geometric distribution and repeated failures are very unlikely.

  \item[State diagram]\hfill\\
    See Figure \ref{fig:state-dia}. The application starts in the ``New game''
    state. From any state, the player can go to the ``New game'' by starting a
    new game. From any state, the player can save the game and stays in the
    same state. From any state, the player can go to the ``Game play (no high
    score)'' state by loading a saved game. From any state, the player can go
    to a ``High score list'' state to see the current high score, and go back
    to the original state.
    \begin{figure}[htb]
      \begin{center}
        \includegraphics[scale=0.5]{state-dia.png}
      \end{center}
      \caption{Application state diagram}
      \label{fig:state-dia}
    \end{figure}

  \item[Contributions]\hfill\\
    Gary Roumanis implemented the hint mode, the save/load functionality and
    the high score list.

    Andrew Sutcliffe enhanced the GUI, implemented the timer and provided the
    unit tests.

    Shen Chen Xu implemented the generation of solvable boards, the undo/redo
    functionality, prepared the state diagram and the report.

\end{description}
\end{document}
